System for providing flexible charging in a network

ABSTRACT

The present invention relates to arrangements for charging in a packet switched network. Packets are charged differently dependent on which service flow the packets belong to. The charging system comprises a control system and a serving element residing in a packet forwarding system wherein said control system comprises an account function adapted to manage an account of at least one user and a charging policy decision point arranged to calculate a charging policy for allowed services for the at least one user. Moreover, said serving element comprises a token bucket per user adapted to store reservations received from the account function of the user associated with the token bucket and a charging policy enforcement point arranged to perform charging for a plurality of the allowed services by reducing the stored reservation of the token bucket according to the calculated charging policy.

FIELD OF THE INVENTION

The present invention relates to packet switched communications systems,and more particularly, to arrangements for performing charging in realtime.

BACKGROUND OF THE INVENTION

Packet switched communications systems transport many different types oftelecommunications traffic, such as voice, data, and multimedia traffic,which originates from a large variety of applications. A networkoperator may provide a variety of services that uses the different typesof traffic and having a variety of charging schemes.

For some services, e.g. streaming, it is suitable to apply a time-basedcharging in contrast to other services e.g. internet browsing, wherevolume related charging is the only possible (usage related) chargingmethod. The choice between time-based , volume-based and service basedcharging is made in relation to what the subscribers are willing to payfor and also to achieve an accepted understandable charging method.E.g., for a streaming application such as a video stream, it isunderstandable for the user to pay for consumed time that he has watchedthe video.

A subscription may have one or more users. The subscription is either apre-paid or a post-paid subscription, which implies that the subscriber,either in the pre-paid case pays an amount in advance, i.e. prior theservice(s) is (are) utilised or in the post-paid case pays for e.g. thetime or data volume that he actually has used during a certain period oftime. In order to support pre-paid subscriptions, the charging solutionhas to have “real-time” properties. This is particularly important whena prepaid subscriber's credit account is empty, service execution (inthis case packet forwarding) must be immediately affected. When asubscriber account is empty, the operator wants to block at least allservices that are subject for charging, since the operator wants to havecredit control in addition to prevent loosing money because ofnon-payment for consumed services. Some free of charge services maystill be open for the subscriber like refill of the account, call toemergency numbers, self-care pages and in some cases also reception ofSMS/MMS messages.

Thus, it is desirable to be able to perform a differentiated rating onthe packet level based on the service. Performing differentiated ratingon the packet level raises however a fundamental challenge, since ratingis a complex process involving many input parameters such as tariffplan, time and volume thresholds, subscriber profile, etc., while thepacket forwarding should be executed with lowest possible latency. Thus,packet forwarding systems and rating engines, respectively, havedifferent system requirements.

Herein, the charging system according to prior art is called a “multipletoken bucket” system. Such a system comprises a control system and apacket forwarding system as disclosed in FIG. 1. The control system 101comprises a rating engine 102 and credit accounts 103. The packetforwarding system 104 comprises one token bucket 105 per service flow106 and user which results in multiple token buckets 105 for everylogged-in user provided that multiple services are used.

When a user logs into the communication system, the packet forwardingsystem 104 initiates a control signalling sequence to the control system101 for each service. The control system 101 reserves a preconfiguredamount of credit towards the subsciber's credit account, wherein thisamount is called a “credit reservation”. The control system 101determines the set of services this user is allowed to use. The set ofidentifiers for these allowed services are sent to the packet forwardingsystem. For each service identifier, the packet forwarding system 104initiates a resource reservation signalling sequence towards the controlsystem. For each such sequence, the service is rated by the ratingengine 102 of the control system 101, using a tariff plan. The ratingvalue is used to translate parts of the credit reservation into a“resource reservation” (typically data volume related), which is sentback to the packet forwarding system 104. Each resource reservation isput into a specific resource token bucket 105. Thus, the packetforwarding system 104 contains multiple token buckets 105, one for eachallowed service per user.

When traffic is flowing through the communication system the packetforwarding system 104 classifies each packet to determine which serviceflow it belongs to. Then the token bucket 105 for that service isdecremented. When a token bucket 105 is empty, the usage is confirmedtowards the control system and a new resource reservation is done.

Thus, the multiple token bucket solution that performs per-packetreal-time charging in a packet switched communication system, whereinthe packets are charged differently dependent on which service flow thepackets belong to, requires a separate resource reservation signallingsequence for each service flow in the set of allowed services. Thiscreates a large amount of signalling traffic between the control systemand the packet forwarding system. In addition, it requires highprocessing capabilities in the control and the packet forwarding system,respectively, and high capacity transport between said systems.

Furthermore, the multiple token bucket solution have other drawbackssince unnecessary reservations are performed. In the multiple tokenbucket case, a pre-configured amount of resources is reserved for eachservice, wherein the credit reservation of each token bucket isdedicated for a specific service flow. That implies that creditreservations made for services not being used cannot be utilised foranother service that actually is being used. Thus, this results in theabove unnecessary reservations. Moreover, the problem gets worse as thenumber of services increases.

Another possible solution is to use several GPRS Access points Names(APN) in a mobile telecommunication network for differentiating betweendifferent consumer service flows. An APN is a label of one or moreservice flows in a mobile cellular network. However, this solution hasdisadvantages due to APN configuration management, in e.g. terminal andnetwork, as well as IP address handling in the terminal. Thus, thissolution requires additional management for the operator to setup andcontrol.

Network operators prefer hence a solution with multiple services perAPN, preferably one APN for all service flows.

SUMMARY OF THE INVENTION

As mentioned above, a multiple token bucket solution of prior artrequires a large amount of signalling traffic between the control systemand the packet forwarding system. In addition, the multiple token bucketsolution is in many cases subject to the above mentioned unnecessaryreservations. Furthermore, it is desirable to achieve a solution wheremultiple service flows are connected to one Access Point Name (APN) in amobile cellular network, since solutions with one service flow per APNhas drawbacks relating to configuration management as explained above.

Therefore, a first object of the present invention is to achievearrangements for providing a flexible realtime charging, whereby thesignalling between the control system and the packet forwarding systemis reduced.

A second object of the present invention is to prevent unnecessaryreservations.

A third object with the present invention is to provide a chargingsystem where service flows can be differentiated at packet level andapplicable charging can be applied in a flexible way. I.e., each packetshould be able to be charged differently dependent on which service flowthe packets belong to.

A fourth object of the present invention is to achieve a solutionfacilitating multiple services per APN.

The above stated objects are achieved by means of a system according toclaim 1, a control system according to claim 12, a serving elementaccording to claim 18.

The charging system according to the present invention makes it possibleto reduce signalling between the control system and the packetforwarding system. The charging system comprises a control system and aserving element residing in a packet forwarding system. Said controlsystem comprises an account function adapted to manage an account of atleast one user and a charging policy decision point arranged tocalculate a charging policy for allowed services for the at least oneuser. Said serving element comprises a token bucket per user adapted tostore reservations received from the account function of the userassociated with the token bucket and a charging policy enforcement pointarranged to perform charging for a plurality of the allowed services byreducing the stored reservation of the token bucket according to thecalculated charging policy.

According to a first embodiment of the present invention the reducedrisk for unnecessary reservations towards the account function isrealized by having a single token bucket that is shared by a pluralityof service flows per user.

Another advantage of the present invention is when a rate change shouldbe performed at a certain time-of-day (ToD), the signalling load may bereduced by including, in the charging policy, the user rating tablepart, rates both before and after ToD. Furthermore, when a user creditaccount becomes empty or a predefined threshold is reached, it ispossible to apply a fine-grained policy control of the traffic thanks tothe charging policy.

Another advantage of the present invention is that the use of a singletoken bucket per subscriber concept reduces the distribution of tokenreservations in the network which hence reduces the risk to empty theprepaid account due to many different reservations. It also reduces thecontrol signalling between the serving element and the gateway andeventually the pre-paid system, thus reducing the needs of physicalboxes for all three functions.

Another advantage of the present invention is that the service classconcept allows the operator to group related services into a number ofgroups, i.e. the services having identical tariffs in one group. Thus,the relation between the services in the same service class could bearbitrary except that the tariff must be the same since the rating isbased on the service class. Still, each user could have differenttariffs for a particular service class, but for a particular user, allservices in a service class will have the same rating (at a particulartime) which means that all packets belonging to a certain service classare rated in accordance with the rating value associated with thatservice class in real-time without need for control signalling towardsthe rating engine. The benefit besides the service grouping is that theamount of data per subscriber is dramatically reduced. As an example,the number of services may be in the order of thousands but the numberof service classes may be up to hundred. The service class concept isalso the basis for operator-side service authorisation. In addition, theservice class concept reduces the complexity for the user (the chargingscheme for different services may be easier to understand), speeds upthe processing of the charging system e.g. since the size of the userrating tables decreases.

Another advantage with the present invention is that the delay whenstarting to use a service (for example when retrieving MMS messages) isreduced which results in a better end-user satisfaction and higher datathroughput. That is achieved due to the dynamic pre-rating at subscriberconnection which implies that all applicable rating values includingtheir validity conditions are calculated before the subscriber starts touse the different services. It also reduces the control signallingtraffic thus reducing the load of the rating engine. Both traffic datathroughput enhancement and control signalling traffic reduction may leadto fewer physical boxes in the network. A high level of ratingflexibility is maintained as the rating values have well-specifiedvalidity and may be re-newed.

A further advantage of the present invention is that the service filterand the protocol inspection filter (PIF) concepts allow the operator tospecify filter rules for a service that may increase the traffic datathroughput by just assigning rules in the service filter, while stillhaving the possibilities to invoke more advanced filter rules whennecessary to distinguish the service. Thus, the PIFs are only used if itis not possible to differentiate between the service flows by means ofthe service filter, i.e. by using the IP address, which results in ahigher throughput at the packet forwarding system. The concepts as suchare general which allow for further inclusion of new rules when neededfor other services.

A further advantage of the present invention is that the charging systemis arranged to handle “one-time initial charge”. An initial amount oftokens are decremented from the token bucket before or during the startof the service.

Further advantages and objects of embodiments of the present inventionwill become apparent when reading the following detailed description inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram illustrating the multiple tokenbucket solution according to prior art.

FIG. 2 is a schematic block diagram illustrating a single token bucketsolution according to one embodiment of the present invention.

FIG. 3 is a schematic block diagram illustrating a process ofcalculating the “charging policy” in accordance with the presentinvention.

FIG. 4 illustrates the charging policy schematically, containing userrating table and validity conditions in accordance with the presentinvention.

FIG. 5 illustrates the user profile schematically.

FIG. 6 illustrates the tariff plan schematically.

FIG. 7 a illustrates the parameters of service filters.

FIG. 7 b illustrates the parameters of a Protocol Inspection Filter(PIF) configuration.

FIG. 8 illustrates the serving element in accordance to one embodimentof present invention implemented in a GGSN in mobile telecommunicationsystem.

DETAILED DESCRIPTION

The present invention now will be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art. In thedrawings, like numbers refer to like elements.

The realtime charging system in accordance with the present inventionmay be implemented in an IP-network such as the Internet or in a packetswitched mobile telecommunication network such as a GPRS-, UMTS- or acdma2000 system. Even if the embodiments of the present invention aredisclosed in connection with a GPRS-/UMTS system, the invention is notlimited to such systems.

A proposed solution of a charging system according to embodiments of thepresent invention shown in FIG. 2 comprises a control system 201 and aserving element 206. The control system 201 comprises a charging policydecision point 202, also referred to as a rating engine, and a creditaccount function 203, which manages the users' credit accounts forreal-time charging purposes. The serving element 206 comprises acharging policy enforcement point 207 for performing the charging, i.e.managing the reduction of the token bucket 208. The token bucket in theserving element is used per logged-in user and for a plurality ofservices. Preferably, one single token bucket is used for all servicesper logged in user. In addition, the serving element comprises means fordifferentiating packets based on which service flow they belong to. Theserving element may reside in a packet forwarding system such as aswitch, a router, a proxy, a GPRS Gateway Support Node (GGSN) node inthe GPRS/UMTS system, or a PDSN node or Home Agent in the cdma2000system.

The system of the present invention, comprises means for collecting allcredit reservations for a plurality of services in one single tokenbucket per user in the serving element in the packet forwarding system.The credit account function transmits information of the amount ofcredit that should be reserved for all the services respectively, i.e.the services included in a user service vector which is furtherexplained below, to the token bucket of the serving element for aspecific user. The credit amounts are reserved in accordance withpre-configured settings performed by the network operator. Thecollection of all credit reservations for a plurality of services,preferably all, in one single token bucket is made possible thanks tothat a charging policy for the services is calculated in accordance withthe present invention by the control system and transmitted to theserving element. The calculation of the charging policy is hereinreferred to as dynamic pre-rating and is further explained below.

The present invention is applicable on realtime charging for bothpre-paid and post-paid subscriptions. In the post-paid case, a tokenbucket may have a negative value, while in the pre-paid case, the tokenbucket is not allowed to have a negative value since the user is notallowed to use more credits than what is reserved. Moreover, the presentinvention is also applicable on both volume-based, time-based andservice-based charging, dependent on settings of the serving element.

EXAMPLE 1

When a user logs on to a communication system comprising the chargingsystem of the present invention, the serving element initiates a controlsignalling sequence between the serving element and the control system.

The control system determines the set of service identifiers this useris allowed to use. The rating engine 301 of the control systemcalculates a charging policy 304 based on a tariff plan 303 and otherinput data e.g., Time of Day (ToD), the user's roaming status, theaggregated transferred data volume for the user and other user specificusage history. Current usage behaviour is also utilised at thecalculation of the user rating table if the user already is logged on,e.g. in a situation when the token bucket of the user runs empty, i.e.one validity condition is not fulfilled, and the serving elementrequests a new user rating table from the control system. Thiscalculation is illustrated in FIG. 3 and is called dynamic pre-rating.The charging policy comprises a user rating table 305 and a set ofvalidity conditions 306. The user rating table 305 includes ratingvalues for each service class the user is allowed to use and the set ofvalidity conditions defines the conditions when the user rating table isvalid. The service class concept is introduced according to the presentinvention to limit the size of the user rating table of the chargingpolicy. The service class is a group of services with the commonproperty that they have exactly the same charging pattern, i.e.identical tariff plans. The calculated charging policy is sent to theserving element in the packet forwarding system.

Next, the serving element in the packet forwarding system initiates areservation signalling sequence towards the credit account function ofthe control system. The credit account function reserves an amount ofcredit according to pre-configuration settings towards the user's creditaccount, wherein the amount is called a credit reservation. The creditreservation is made for a plurality of service, preferably all services,and the overall credit reservation is sent to the serving element andput into the user-specific token bucket.

When traffic is flowing via the packet forwarding system, the servingelement in the packet forwarding system comprises means for classifyingeach packet to determine which service class it belongs to. The receivedcalculated charging policy is used to determine the credit amount thatshould be decremented from the token bucket. It should be noted that thedecrement may also be negative in order to support bonus services, i.e.a user gets paid if he uses a specific service.

The serving element in the packet forwarding system continuously checksif the validity conditions of the charging policy still are valid.Examples of validity conditions are time, thresholds for the tokenbucket, geographical area etc. When the validity conditions no longerare valid, a signalling sequence is initiated to get a new up-datedcharging policy. When a rate change should be performed at a certaintime-of-day (ToD), the charging policy, i.e. the user rating table part,contains the rate values that should be used both before and after ToD.That results in that the charging policy for a huge amount of users doesnot have to be updated at the same time which would cause extensivesignalling during a short limited period of time for the huge amount ofusers, but the update may be performed during a longer period of timewhich reduces the signalling peak load.

FIG. 4 shows an example of a charging policy comprising a user ratingtable associated with validity conditions.

When a token bucket is empty or a predefined threshold is reached, theusage is confirmed towards the control system and a new resourcereservation is done. In the confirmation signal, information about theusage of the different services may preferably be added explicitly.

Basic Terminology

In the following, the basic terminology of the flexible bearer chargingsystem in accordance with the invention is explained:

-   -   A user is person having access to the operator's provided        services.    -   One or more users may be connected to one subscription.    -   A subscriber is the owner of the subscription.    -   Realtime charging implies that the charging process is performed        while or after the service has been requested. It should be        noted that 3GPP uses the term “on-line charging”.    -   A token is similar to a ticket. A utilisation of a service        requires a predetermined amount of tickets/tokens, based e.g. on        either the traffic volume or on the used time.    -   A token bucket is a place where all tokens for one user is        collected.    -   A service, is the collection of all IP flows to and from a        specific destination, determined by information in the headers        or payloads of the IP packets.    -   A service identifier, is the unique identifier of a service.    -   Service class is an identifier of an arbitrary group of services        that the operator wants to treat in the same way regarding e.g.        charging and service authorization. One service is allowed to        belong to only one service class at a time per user.    -   A tariff plan is a specification of prices for the services and        when the services are valid.    -   A rating value is an amount that should be reduced from the        token bucket for a specific service.    -   A service class according to the present invention comprises all        services having identical tariff plans.    -   A service filter, is a specific filter setting that will handle        a service with a specific service identifier. Thus, the service        identifier is used to map the service to its service filter.        This terminology is further described below. In each service        filter, destination or/and source (depending on the traffic        direction) IP addresses (and mask), TCP and UDP port numbers        (ranges), and protocol numbers can be set. In order to handle        inspection of higher protocol layers, a service filter may        include a pointer to a Protocol Inspection Filter (PIF), which        perform stateful packet inspection. The packet inspection is        performed dynamically in contrast to the static service filters.        That implies that the PIFs e.g. performs packet inspection based        on previous events. The PIFs have specific configuration data        (see FIG. 8 b), for example containing URIs. Dynamic filters are        established to perform the actual filtering for packets that fit        to the defined PIF rules. Finally, service filters and PIF        configuration lines contain the service class identifier that        represents the result of a filter matching an incoming packet.        The service class identifier identifies the service classes and        hence determines the rating that will be applied to the packet.        Service filter and PIF configurations are preferably performed        in the packet forwarding system on a per Access Point Name (APN)        basis.

PREFERRED EMBODIMENTS OF THE PRESENT INVENTION

The charging system and method of the present invention will hereinafterbe described in conjunction with a GPRS/UMTS system. Thus, oneembodiment of the charging system implemented in a mobiletelecommunication system such as GPRS or UMTS system according to thepresent invention comprises:

-   -   A serving element 801 located in a GGSN 800 as illustrated in        FIG. 8. The serving element is further described below.    -   A control system comprising a rating engine in accordance with        the present invention i.e. the charging decision point, which        allows the operator to define services and tariff plans, and        dynamically provides the serving element with rating information        in form of charging policies. The control system comprises        further a credit account function.    -   A gateway, which provides an integration point for interworking        towards the operator's prepaid system by means of flexible        interface options. In the case when the pre-paid system supports        e.g. a Radius interface, the GGSN is arranged to directly        interface to it.

It should be noted that even if the charging system and method thereofaccording to embodiments of the invention is described in conjunctionwith a GPRS/UMTS system in the following, the system and method thereofare not limited to such a system but may also be used in other packetswitched communication systems.

Differentiated Packet Rating

As described above, differentiated rating on the packet level is acomplex process involving many input parameters (tariff plan, time andvolume thresholds, subscriber profile, etc), while packet forwardingshould be executed with lowest possible latency.

The charging system of the present invention employs a rating process intwo stages:

-   -   A dynamic pre-rating process providing the charging policy,        which is performed by the rating engine of the present        invention.    -   A real-time packet rating e.g. performed, in accordance with the        provided charging policy, by the serving element in the GGSN.

The dynamic pre-rating process calculates a charging policy comprising aset of rating values for each service class that a subscriber is allowedto use. The charging policy comprises user rating table and a set ofvalidity conditions. This calculation utilises the tariff plan and thecurrent subscriber situation e.g. roaming status, time-of-day, etc. Therating values have a limited lifetime according to the set of validityconditions and have to be renewed for example when a tariff threshold isreached. The validity conditions may also relate to other parametersthan the time. The dynamic pre-rating is performed and the chargingpolicy is thus provided to the serving element before the user startsusing any services.

The real-time packet rating is then performed by classifying a packet asbelonging to a certain service class and using the already calculatedrating values for that packet. This can be done with a very small delayin the forwarding process, since signalling between the control systemand the serving element in forwarding system for each service initiationis avoided.

For example, a case is employment of zero volume-charge for servicesthat have service-based charging (e.g., MMS). For such services, thedynamic pre-rating process would result in a rating value of zero. Thereal-time packet rating will then use the zero value and hence incurringno charge for that traffic.

Rating Engine

FIG. 3 illustrates how the rating engine of the preferred embodiment ofthe present invention performs the dynamic pre-rating process byproducing a user rating table. The user rating table is produced bycombining the user service class vector, the tariff plan, and additionalinformation such as roaming status, aggregated volume and connect timestored in the database of the rating engine, time of day, andgeographical location. In addition to the user rating table, acorresponding set of validity conditions are generated using tariffthresholds in order to produce the charging policy. The charging policycomprising the user rating table and the validity conditions is providedto serving element e.g. located in the GGSN.

More specifically, the rating engine comprises means for performing thefollowing procedure:

-   -   Accepts request for a user rating table; wherein the input of        the request may be a user identifier, e.g. the MSISDN, SGSN        IP-address, QoS of the PDP Context, etc.    -   Receives the user service class vector of the subscriber which        is further described below.    -   Receives the service definition for each service class in that        subscriber's user service class vector.    -   Receives the aggregated volume, e.g. the transfer history, and        aggregated connect time for this user (preferably stored in the        internal database of the rating engine).    -   Calculates roaming status based on SGSN IP address for each        service class.    -   Calculates the relevant rating values using the tariff plan and        relevant rating dimensions, e.g., information about the user's        roaming status, aggregated volume and connect time, ToD, and        geographical location.    -   Calculates the validity condition for these rating values using        the tariff thresholds in the rating dimensions such as roaming        status, aggregated volume and connect time stored in the data        base of the rating engine, ToD, and geographical location    -   Constructs the user rating table based on the above mentioned        calculations.    -   Sends the constructed user rating table and the calculated        validity conditions in form of a charging policy according to        the present invention to the charging enforcement point of the        serving element in the packet forwarding system.        Serving Element

According to the present invention the serving element, residing in apacket forwarding system 800, comprises the charging enforcement point802, means 805 for performing the service classification and one tokenbucket 803 per user handling a plurality of services, preferably allallowed available services. Thus, in the embodiment described above, theserving element is included in a GGSN 800. FIG. 8 shows an overviewblock diagram of the function of the serving element.

The service filter and PIF configurations are configured in the servingelement. In a GPRS/UMTS network, that is preferably performed by usingthe operation and support system of the Core Network. The servingelement is arranged to perform packet inspection according to theservice filters. In some cases, when necessary, it also invokes ProtocolInspection Filters (PIFs) for analysis of higher-layer protocols.

For the pre-paid and post-paid subscribers, the serving element mayutilize the dynamic pre-rating and the reservation mechanisms asdescribed above. The serving element distinguishes between post-paid andpre-paid subscribers either by using the charging characteristicsinformation or by analysis of the subscriber identity, e.g. the IMSI incase of a mobile cellular network. The serving element may be configuredto retrieve the user service class vector for both pre-paid andpost-paid subscribers in order to perform operator-side serviceauthorization. Moreover, the serving element is arranged to performcredit control for both post-paid and pre-paid subscriptions.

The serving element requests user rating tables from the rating engine.This is triggered either at connection setup such as by PDP ContextActivation or that the validity conditions for the user rating table areno longer valid. When a new user rating table is requested, the servingelement reports to the rating engine the transferred volume and theconnect time as well as the status of the “initial rate values”.

The serving element comprises means 804 for making reservations towardsprepaid and postpaid system, via a gateway, and thereby fills up eachuser's token bucket kept in the serving element of the packet forwardingsystem, e.g. the GGSN. The amount of reservation and the validityconditions are configurable in the serving element. It decrements eachuser's token bucket according to the user rating table.

Service Classification

The service classification is performed by means in the serving elementin the packet forwarding system. In accordance with one embodiment ofthe present invention, the means for classifying packets are servicefilters and/or PIF. Thus, the classification is performed based on IPheader information and/or higher-layer protocols. While the architectureof the system according to one embodiment of the invention supportsgeneral stateful inspection and identification of URIs, initial focus isput on detecting MMS traffic over WAP 1.x and 2.x. After a packet hasbeen classified to belong to a certain service and service class, thereal-time packet rating determines a rating value according to thecalculated charging policy. The token bucket is then adjusted inaccordance with the determined rating value.

The serving element in the packet forwarding system, preferably theGGSN, in accordance with the present invention is also adapted toenforce certain policies when the subscriber's prepaid account runsempty. Depending on roaming conditions, PDP Contexts can be de-activatedor non-zero-rated packet can be stopped, while zero-rated traffic is letthrough e.g. allowing access to top-up pages, i.e. a default web pagethat the user enters when the credit account is empty. It may e.g. bepossible to refill the account from such a top-up page.

The benefit for the network operator of this above mentioned two-stageapproach is that if throughput and latency are most important, servicessuch as email, instant messaging, traffic to corporate gateways, andtraffic to Internet may be defined using only IP-header inspection atthe service filter and the PIF is not required. However, for otherservices such as MMS over WAP, the IP-header inspection (i.e. servicefilter) is not sufficient. A more detailed inspection of the payload, inthis case the URL/URI is required. Thus, this approach avoids theoverhead of stateful packet inspection where it is not required. Thus,one of the basic ideas with the present invention is to start to use theservice filter, and then only if necessary, continue with PIF.

EXAMPLE 2

FIGS. 7 a and 7 b show an example where the operator's WAP gateways areplaced at the subnet 100.18.0.0/16. Assume that these WAP gateways alsoare arranged to function as HTTP proxies. The service filters 1 and 2both match packets to and from that subnet. Filter 1 is set to match thetransport protocol Wireless Session Protocol (WSP) and invoke PIF number1 according to the PIF pointer in FIG. 7 a, while filter 2 will matchthe transport protocol HTTP and invoke PIF number 2. Assume that anincoming packet is a WAP-packet leading to a match for WSP. PIF 1 nowemploys an identifier data in the PIF configuration, in this case theURL/URI. In this example, it checks for the domain names of theMMS-centers of the operator. If the packet's WSP-header contains any ofthese domain names the resulting service class is 14. If the packetcontains any other URL (the wild card *), the packet is non-MMS WAPtraffic and is classified as service class 15.

Referring back to FIG. 7 a, the service filter with the serviceidentifier 3 is set to match the subnet 100.12.0.0, which for example isa partner service provider. All packets to and from that serviceprovider will be classified as service class 22. Finally, packetsmatching the wildcard rule, service filter with service identifier 4,representing “other traffic”, will be classified as service class 60.

User Profile and User Service Class Vector

A user profile which is illustrated in FIG. 6 includes a subscriberidentifier, the MSISDN, together with a user service class vectoraccording to the present invention. The user service class vector is alist of the services the user is allowed to use.

Specifically, if the operator wishes to perform operator-side serviceauthorisation, the user service class vectors may be used to controlwhich service classes a subscriber is allowed to access. The userservice class vectors are provisioned through a service authorisationand subscriber provisioning system. This allows for self-provisioningvia the subscriber portal, which also forms the basis for top-up pages.Note, if the operator does not want to employ service authorisation allavailable service classes should be listed in the user service classvector.

Continuing with the example described in conjunction with FIGS. 7 a and7 b, the user profile in FIG. 5, allows the user to access serviceclasses 14 (MMS traffic), 15 (other WAP traffic), 22 (the partnerservice provider), and 60 other traffic (general Internet access). Theuser profiles are managed by a customer relation management system andmay be stored in a common directory. Independent of where the userprofiles are stored they are replicated down to the rating engineaccording to the present invention.

Referring back again to the example in previous sections, FIG. 6 shows asimplified tariff plan where service class 14 (MMS traffic) iszero-rated except when the subscriber is roaming, Service Class 15(other WAP-traffic) is rated −2 tokens per byte. Traffic to and from thepartner service provider (Service Class 22) is free-of-charge exceptwhen roaming. These rating dimensions are independent and can becombined, so that a specific rate would apply, for example, between 6 pmand 6 am, above 3 MBytes, when roaming. The tariff plan in FIG. 6 isonly a schematic simplification of the method used by said rating engineof the present invention.

For each service class in the user service class vector, the dynamicpre-rating calculation generates five rating values: an “initial ratevalue”, two “current rate values” and two “next rate values”. Furtherinformation on the interaction between the tariff plan and the userservice class vector is explained below. The initial rate value is equalto the number of tokens that should be deducted when either a serviceclass is used for the first time or for the first used service classdepending on a configuration value for that subscriber. Thus, theinitial fee may be based on service or subscriber.

To handle different settings of the meaning of “first time” e.g. per dayor month, the information of the application of the “initial ratevalues” to be used for the next dynamic pre-rating calculation issupplied to the rating engine. The “current rate values” is the numberof tokens per byte to be charged for packets belonging to a serviceclass that shall be used immediately. See validity conditions below. Thereason to have two “current rate values” is to allow different ratingvalues for uplink and downlink traffic, respectively. The “next ratevalues” shall be used after the expiration of the “current rate values”.The purpose of the “next rate values” is to manage mass updates at acertain time. I.e., the charging policy for a huge amount of users doesnot need to be updated at the same time which would cause extensivesignalling during a short limited period of time for the huge amount ofusers, but the update may be performed during a longer period of timewhich reduces the signalling load per time unit during that limitedperiod.

All these rating values of the charging policy 400 are listed perservice class to form the user rating table 401 as shown in FIG. 4. Theuser rating table has a limited lifetime, specified by a set of validityconditions 402, which are calculated using the tariff thresholds fordimensions such as: roaming status (home or away), geographicallocation, Time-of-Day (ToD) including month, year, etc, aggregatedvolume which is also referred to as transfer history, aggregated connecttime, QoS of the connection, i.e. of the PDP Context for a GPRS or UMTSconnection. It is the responsibility of the serving element to requestan updated user rating table when a threshold associated to avolume/time/location is reached. Thus, the charging system useshistorical and/or current user specific usage data.

The system of the present invention is adapted to support service-basedcharging referred to as “one-time initial charge”. An example of aservice that is charged according the “one-time initialcharge”-principle is a subscription of a newspaper. It may e.g. cost afixed amount per month to be able to read the subscribed newspaper. Inaddition to the fixed subscription fee, a volume or time based fee mayalso be applied. The “one-time initial charge” is supported in two waysby the system of the present invention:

-   -   First by the service class. For each service class in the        subscriber's user service class vector, the arrival of the first        packet classified to that service class implies a deduction of        the initial rate value from the token bucket. The serving        element then puts zero into the initial rate value for that        specific service class.    -   Secondly by the subscriber. All service classes in the        subscriber's user service class vector have the same one time        initial charge value. When a packet arrives for any of the        service classes included in the user service class vector, the        token bucket is decreased with that value and all values are set        to zero. The initial rate value is reported as used to the        rating engine, which then is arranged to give a zero initial        rate value at subsequent requests.

For location-dependent rating, the packet forwarding system sendslocation information to the control system. As an example, the GGSNsupports both forwarding of the SGSN IP address and an interface to aLocation Enabled Server. The packet forwarding system is thus arrangedto check the validity condition concerning geographical location andrequest a new user rating table in case the condition is no longersatisfied.

For time dependent rating the serving element supervises the validitytime condition and requests a new user rating table when a predefinedthreshold is passed. In addition, the serving element supports maximumtime subscriptions, i.e., connection up to 24 hours with one fee. Thisis managed by the remaining time validity condition, the serving elementcomprises means for down counting this value and if reaching zero or apredefined threshold, a new user rating table is requested. If ade-activation of the current connection, e.g. a PDP contextde-activation, occurs before the value has become zero or the predefinedthreshold is reached, the value is sent to the rating engine which isadapted to then update the aggregated time for that user.

For volume dependent rating the serving element supervises the validityvolume condition and requests a new user rating table when a predefinedthreshold is passed. The serving element decreases this value with theamount of traffic that passes and if reaching zero or the predefinedthreshold a new user rating table is requested. If a de-activation ofthe current connection, e.g. a PDP context de-activation, occurs beforethe value has become zero or the predefined threshold is reached thevalue is sent to the rating engine which is adapted to update theaggregated volume for that subscriber.

The control system and the serving element are respectively centralunits of the present invention. The control system is responsible forcalculating the charging policy and providing the charging enforcementpoint of the serving element with that charging policy. The controlsystem is further responsible for managing the credit account of one ormore subscribers. The serving element comprises a charging enforcementpoint that is responsible for performing the charging based on thecharging policy received from the control system. Moreover, the servingelement comprises a token bucket adapted to store credit reservationsfor a plurality of services per user. The token bucket is arranged tocommunicate with the credit account function of the control system.Several different implementations of the control system and the servingelement respectively are possible as will be apparent to the personskilled in the art. It will be apparent to the person skilled in the arthow the control system and the serving element respectively and otherfunctions of the present invention may be implemented using knownhardware and software means. The control system and the serving elementare according to the present invention implemented to be programmable.The easiest way of implementing the programmable control system and thepacket forwarding system may be by means of software means, butprogrammable hardware implementations are also possible as well asimplementations of combinations of hardware and software.

In the drawings and specification, there have been disclosed typicalpreferred embodiments of the invention and, although specific terms areemployed, they are used in a generic and descriptive sense only and notfor purposes of limitation, the scope of the invention being set forthin the following claims.

1. A charging system in a packet switched network for charging packetsdifferently dependent on which service flow the packets belong to, thecharging system comprising: a control system and a serving elementassociated with a packet forwarding system wherein said control systemcomprises: an account function for managing an account of at least oneuser, and a charging policy decision point for calculating a differentcharging policy for each of a plurality of allowed services for the atleast one user, wherein said serving element comprises: a token bucketassociated with the at least one user, said token bucket for storingreservations for a plurality of service flows received from the accountfunction of the at least one user, and a charging policy enforcementpoint for performing charging for the plurality of service flows byreducing the stored reservation of the token bucket according to thecalculated charging policies.
 2. The charging system according to claim1 wherein the charging policy enforcement point includes means forcalculating the charging policies based on historical and/or currentuser specific usage data.
 3. The charging system according to claim 1wherein the serving element comprises means for classifying the servicesinto different service classes based on the tariff plan of the services.4. The charging system according to claim 3 wherein the allowedsubscriber service classes are stored in a Service Class Vector.
 5. Thecharging system according to claim 1 wherein the packet forwardingsystem is a Gateway GPRS Support Node in a mobile telecommunicationnetwork.
 6. A charging system in a packet switched network for chargingpackets differently dependent on which service flow the packets belongto, the charging system comprising: a control system and a servingelement associated with a packet forwarding system, wherein said controlsystem comprises: an account function adapted to manage an account of atleast one user, and a charging policy decision point arranged tocalculate a charging policy for allowed services for the at least oneuser, wherein the calculated charging policy comprises at least one userrating table and a set of validity conditions, wherein said servingelement comprises: a token bucket adapted to store reservations receivedfrom the account function of a user associated with the token bucket,and a charging policy enforcement point arranged to perform charging fora plurality of the allowed services by reducing the stored reservationof the token bucket according to the calculated charging policy.
 7. Thecharging system according to claim 6 wherein the set of validityconditions defines the lifetime of the at least one user rating table.8. The charging system according to claim 6 wherein the charging policyenforcement point includes at least two user rating tables havingdifferent time validity conditions.
 9. A charging system in a packetswitched network for charging packets differently dependent on whichservice flow the packets belong to, the charging system comprising: acontrol system and a serving element associated with a packet forwardingsystem, wherein said control system comprises: an account functionadapted to manage an account of at least one user, and a charging policydecision point arranged to calculate a charging policy for allowedservices for the at least one user, wherein said serving elementcomprises: a token bucket adapted to store reservations received fromthe account function of a user associated with the token bucket, acharging policy enforcement point arranged to perform charging for aplurality of the allowed services by reducing the stored reservation ofthe token bucket according to the calculated charging policy, and meansfor classifying the services into different service classes, saidclassifying means including a service filter adapted to identify thedifferent service flows.
 10. The charging system according to claim 9wherein the means for classifying the services into different serviceclasses further comprises Protocol Inspection Filters adapted toidentify the different service flows, when the service filter is notcapable of said identification.
 11. A control system of a chargingsystem in a packet switched network, said control system comprising: anaccount function for managing an account of at least one user; and acharging policy decision point for calculating charging policies for aplurality of allowed services for the at least one user, wherein thecharging policies are utilized to calculate charges for a plurality ofservice flows using a single token bucket.
 12. The control systemaccording to claim 11 wherein the charging policies are calculated basedon historical and/or current user specific usage data.
 13. The controlsystem according to claim 11 wherein the control system is implementedin a mobile telecommunication network.
 14. A control system of acharging system in a packet switched network, said control systemcomprising: an account function for managing an account of at least oneuser; and a charging policy decision point for calculating a chargingpolicy for the allowed services for the at least one user; wherein thecalculated charging policy includes: at least one user rating table, anda set of validity conditions.
 15. The control system according to claim14 wherein the set of validity conditions defines the lifetime of the atleast one user rating table.
 16. The control system according to claim14 wherein the calculated charging policy comprises at least two userrating tables having different time validity conditions.
 17. A servingelement residing in a packet forwarding system of a charging system in apacket switched network, said serving element comprising: means forreceiving reservations for at least one user, a token bucket for storingthe reservations for the user associated with the token bucket, meansfor receiving a charging policy for allowed services, and a chargingpolicy enforcement point for charging for a plurality of the allowedservices by reducing the stored reservation of the token bucketaccording to a received calculated charging policy.
 18. The servingelement according to claim 17 further comprising a single token bucketper user.
 19. The serving element according to claim 17 furthercomprising means for classifying the services into different serviceclasses based on the tariff plan of the services.
 20. The servingelement according to claim 19 wherein the allowed subscriber serviceclasses are stored in a Service Class Vector.
 21. The serving elementaccording to claim 19 wherein the packet forwarding system is a GatewayGPRS Support Node in a mobile telecommunication network.
 22. A servingelement residing in a packet forwarding system of a charging system in apacket switched network, said serving element comprising: means forreceiving reservations for at least one user, a token bucket for storingthe reservations for the user associated with the token bucket, meansfor receiving a charging policy for allowed services, wherein thecharging policy includes at least one user rating table and a set ofvalidity conditions, and a charging policy enforcement point forcharging for a plurality of the allowed services by reducing the storedreservation of the token bucket according to a received calculatedcharging policy.
 23. The serving element according to claim 22 whereinthe charging policy is calculated based on historical and/or currentuser specific usage data.
 24. The serving element according to claim 22wherein the set of validity conditions defines the lifetime of the atleast one user rating table.
 25. The serving element according to claim22 wherein the charging policy comprises at least two user rating tableshaving different time validity conditions.
 26. A serving elementresiding in a packet forwarding system of a charging system in a packetswitched network, said serving element comprising: means for receivingreservations for at least one user, a token bucket for storing thereservations for the user associated with the token bucket, means forclassifying the services into different service classes based on thetariff plan of the services, wherein the means for classifying theservices into different service classes includes a service filteradapted to identify different service flows, means for receiving acharging policy for allowed services, and a charging policy enforcementpoint for charging for a plurality of the allowed services by reducingthe stored reservation of the token bucket according to a receivedcalculated charging policy.
 27. The serving element according to claim26 wherein the means for classifying the services into different serviceclasses further comprises Protocol Inspection Filters adapted toidentify the different service flows, when the service filter is notcapable of said identification.